1. Field of the Invention
This invention relates to technologies for delivering on-demand services from one computer system, such as a server, to another computer system, such as a client, and especially to such on-demand delivery over a computer network such as the Internet or an intranet.
2. Background of the Invention
Traditionally, as shown in FIG. 3, client computers (31, 32, 33) communicate with and obtain one or more services (36, 37, 38) from one or more server computers (34, 35) via a computer network (30) such as the Internet or an intranet. The server computer may be a platform such as an IBM e-Server equipped with the IBM WebSphere™ application server suite or similar products; the client computer may be a personal computer with a web browser, another server computer, or a suitably equipped portable telephone or personal digital assistant (PDA) or similar product; and the computer network may be a network such as the well-known Internet, a wide-area network (WAN), a local area network (LAN), or other suitable network running common protocols such as Transmission Control Protocol/Internet Protocol (TCP/IP), wireless application protocol (WAP), or equivalent.
The server-provided services may include electronic messaging such as e-mail and America Online's Instant Messenger (“AIM”), to online banking and financial transactions, ordering of goods and materials, performing credit card authorization and charge posting, making travel reservations, etc.
The services (36, 37, 38) offer by each server (34, 35) are traditionally “fixed”, meaning that they are installed or deployed on a server at a particular time, and that from that time forward, they are available for use by the client computers. If changes need to be made to a service, it often must be “taken down” or taken offline, upgraded, and restarted or reinstalled. As such, server system operators, owners and designers must anticipate in advance much of the functionality that will be needed by the clients prior to installing a service.
Further, it has been the business and technical support models of most server operators and technology suppliers to estimate the amount of computing resources needed (e.g. processor speed, memory, persistent storage, communications bandwidth) for a particular set of services running on a given server platform, and to allocate an entire server platform for running the services required. This simplifies maintenance and support, as each server platform is primarily “owned” or “leased” to a single owner, including the services installed on it. If additional computing resources are needed in the future, an owner may authorize upgrading the software services, portions of the server platform hardware, or both. This also simplifies accounting and revenue determinations.
However, as computing platforms have become much more capable (and expensive) in recent years, and as the competitive nature of online services has become a rapidly changing and evolving market, it has become:                (a) less cost effective for individual owners to absorb the full cost of a server platform allocated only to their services;        (b) less predictable as to future server capacity and capabilities which will be required by an owner; and        (c) much less desirable to install and uninstall “fixed” or static application programs, servlets, and the like.        
As illustrated by FIG. 4, many of these services (36, 37, 38) may include functions which are unique to each service (41, 42, 43, 44, 45), and a few which are similar or identical to other functions (40, 42) in other services. Even though programming is usually approached in a modular methodology today, many of the deployed application programs reuse these functions (e.g. modules, methods, etc.) with the structure or design of the service being relatively static. For example, Function A (40) may be a function to open, read, write, and close a banking ledger file, while Function C (42) may be a function to perform a daily balance and interest calculation. So, Fixed Service 1 (36) may open a ledger file (40); obtain new entries to the ledger using Function B (41) such as electronic fund transfers, charges, checks, etc.; repeat a cycle of calculating a daily balance and interest due (42) and entering new transactions (41); until no further transactions are to be processed (e.g. closing of a reporting period) when the ledger file is updated and closed (40), as shown in FIG. 6. Fixed Service 3 (38) may also need to calculate interest as done by Function C (42), albeit in conjunction with other functions to perform a different service than Fixed Service 1 (e.g. to prepare a tax report on an account or set of accounts).
Some architectures have been developed to allow for services to use functions provided by external programs such as the Common Object Request Broker Architecture (CORBA), as illustrated in FIG. 5. In such an arrangement, each service (36, 37, 38) must be designed with the expectation of using a common object or function (40, 42). During runtime, the service may post a request to an object-request broker (50), which locates an available object, and provides an interface to the needed objects. While this is useful in minimizing the actual code content of each service (by allowing the service to use the code in the common objects), it still requires the designer of each service to anticipate what functions will be needed and when they will be needed in the logical processes of the service, as shown in the example of FIG. 6.
Many technology providers, such as International Business Machines (IBM), have set their business goals to be able to offer “dynamic on-demand” services, which allow sharing of server platform resources across multiple “owners” on a dynamic basis, and which provide greater support for dynamically provisioning services as demands for the functions they provide vary over time.
The delivery infrastructure required by on-demand computing services poses a great deal of challenges and complexity. Foremost of these challenges is the lack of homogeneity as exhibited by the multiple platforms and programming systems that run the components of such service delivery infrastructures. This exacerbates the issue of interoperability, makes it difficult to incrementally add new services to accommodate the dynamic nature and the rapid pace at which those services need to become available.
Additionally, this situation prevents the adoption of a unified model for securing exchanged messages when needed as might be the case when transporting messages over public networks such as the Internet. Exchanged messages communicate on-demand service requests and responses between on-demand service users and the provider of those services, or they may carry information about the necessary service provisioning that takes place within the provider's realm in servicing those requests as well as possibly joining various business partners.
Once an underlying infrastructure is developed for provisioning, deploying, and executing such on-demand services, proper accounting methods may be employed to allow for more granular methods of revenue generation, cost sharing, and usage tracking. For example, if a service can be dynamically deployed for a banking service only as clients request the service, the bank can avoid paying for unused resources (e.g. unused processor time, memory, disk space, communications bandwidth, etc.) during periods of low or no use of the service, and other owners of services may be provided the unused resources for their burgeoning service requirements (e.g. a travel service may be experiencing peak demand for reservation actions). The technology provider, such as IBM, may then dynamically share computing resources (hardware and software) among multiple service owners, receiving revenue for services based upon appropriate models such as a base fee plus a metered usage fee.
Therefore, there is a need in the art for a uniform and a dynamic service request and delivery infrastructure that addresses the challenges of industry interoperability and complexity of service scalability, which avoids the static or fixed nature of service design, and which supports metered accounting for enhanced revenue generation and cost sharing.